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(g) A computerized system and process for managing a distributed database system. 



<£> In a distributed data processing system compris- 
ing a plurality of different computer systems, each 
system having a central processing unit (CPU), 
memory, a database stored in the memory, and a 
DBMS, a computerized method is provided lor gen- 
erating a plurality of objects in a standardized for- 
mat A unique object identifier Is associated with 
each of the plurality of objects. Each unique object 
identifier is stored In memory in association with at 
least one object location type or instance, an object 



generation specification for each object location type 
or instance, and a generation specification type. For 
a requested object type at a specified location, iden- 
tifying from the computer memory an object genera- 
tion specification, and a specification type. The re- 
quested object Is generated In a standardized format 
from the specified location using the identified pro- 
cess type and the identified object generation speci- 
fication. 
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Field of the invention 

This Invention relates to comput r systems 
having database management systems fu? storing 
organizing and retrieving data. More perucut&ily. $ 
this invention relates to managing a .distributed 
database . management system (DBMS) intercon- 
necting different types of database management 
systems, • 

Background of the Invention 

In a dynamic business environment whoro 
timely access to data is important computerized 
databases are commonly used to store, data for is 
easy retrieval and organization. The data is stored 
electronically In mass storage devices Several 
computer software programs collectively called a 
database management system are used to manipu- 
late the data for- retrieval, deletion updates and 20 
storage 

One type of DBMS used by many enterprises 
Is a relational database management system * - 
(RDBMS) An RDBMS is a body of related informa- 
tion stored in a computer organized as tables hav- 25 
Ing columns and rows. The columns correspond to 
attributes of relations and rows correspond to a 
relation grouping called a tuple. For example, an 
Inventory table could have attributes -such as an 
inventory item number, a description of the item, a 30 
quantity In stock, a price and a supplier. Each 
column corresponds to an attribute -and each row is 
a tuple comprising the. attributes for a given item 

Large enterprises with many remote business 
locations frequently have data stored at each sepa- $5 
rate location. For example, a large retail business 
having numerous outlets many miles away from 
each other could have separate databases at each 
location keeping track of that store's inventory The 
local databases are accessible by local sales staff 40 
for information about items In stock locally How- 
ever, central purchasing staff for the business also 
need to access the information regarding each . 
store's inventory. 

The databases at each location can be linked 46 
together through communications systems so that 
the databases can all be reached from a central 
location, A distributed relational database network 
consists of a collection of tables spread across a 
number of computer systems having the same or 50 
different types of DBMSs that are interconnected In 
a network Each computer system In the network . 
has Its own DBMS to manage data locally stored in 
its environment Each of the remote locations may 
be using one of many different DBMSs that are 5$ 
currently available. These DBMS types and each 
version release thereof have different features and 
functionalities 
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Accessing data from remote locations can be 
difficult for both database users trying to retrieve 
Information from databases and for programmers 
creating programs using th data. It is even- more 
d/fficurt to access data at a remote location which 
has a different DBMS. 

For large enterprises having many remote loca- 
tions with different DBMSs, a programmer has to 
know many (Efferent DBMS commands, syntax and 
structure to access or control access to data at 
each remote site. Also, to perform correctly, the 
resulting programs must be designed and buift to 
toko into account the differences and special abili- 
ties of each remote system, the. database eyetem 
types that are on each system, the databases, 
contents of each database (eg., tables and table 
columns) and the authorizations allowed for each 
part of each database. 

The database type, the database, end the au- 
thorization are termed object types* while the actual 
databases stored in the systems, the tables in the 
database, the columns of the tables, and the au- 
thorizations on each table and column are termed 
occurrences or instances of a system obfect type. 
. Materialization of objects refers to the process of 
creating a representation of .the object by, for ex- 
ample, retrieving or organizing data In memory 
The programmers need to know the object types in 
a system, the object occurrences, the relationships 
between objects, the actions that, can be performed 
on a given object, and the way objects are materi- 
alized, for each of the systems in the network 

The programmers especially need to be cog- 
nizant of the differences in processes to. generate 
lists of object occurrences in each system type 
When each computer, system has its own unique 
command set and syntax, there is an even greater 
need for a programmable process to control and 
facilitate the addition of new object types, relation- 
ships, and occurrence generators for all of the 
different systems . . 

Therefore, there b a need for a. standardized 
method of retrieving all of the various objects in a 
distributed database system. It is important for 
such a method to be table or control file driven and 
to be dynamically extendable to provide for future 
additions of new objects and the relationships be- 
tween objects being managed by the system. ' 

There is also a need for flexibility in the design 
of the control tables used by the system Managing 
a distributed database system. The distributed sys- 
tem is continually being changed to contain new 
object occurrences or Instances (such as 4 particu- 
lar table), object types (such as a new type of 
authorization privilege), and relationships ]between 
object types and the actions to be performed on 
object occurrences (such as copying, adding or 
deleting objects) Prior programming methods of 
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encoding algorithms for obtaining * entity-type and 
entity-Instance relationships and the related pro** 
gram functions to perform various actions on the 
object instances or occurrences have typically re- 
quired the creation of specific purpose code which 5 
is unique to the relationship of entities, the entity- 
type or the instance mater ialrzation technique Tra- 
ditionally, the specialized code is embedded in 
each program that processes that entity or object 
For etxampfe, it 19 common practice to embed to 
within a program module, the programming algo- 
rithm necessary to locate entity-to-entity relation- 
ships, determine methods of materializing specific 
instances of the relationship, call methods of ma- 
terializing specific to instances of the entities, and re 
optionally providing for addition of new object, 
types and actions. This practice results ir> duplica- 
tion of effort when the entities are involved in 
multiple solutions as occurs in managing a distrib- 
uted system* Therefore, for managing a distributed 1 so 
system there is a need for providing a standard* 
teed object list retrieval system that is decoupled 
from object instance utilization functions such as 
display routines 

25 

Summary of. the Invention . 

•It is an objective of this invention to place 
information regarding the logic of generating object - 
occurrences and object relationships into tables : so . 
rather than embedding the logic information In the 
generation code- 
System objects and relationships arid changed 
or added by changing table entries instead of hav- < - - < 
ing to change the process itself Object and rela- 35 
tronship -definitions and- materialization specifica- 
tions ere stored and processed* outside the oper- 
ational scope of the process* which . requires that 
Information about the object instances or relation- 
ships be returned. It is an objective of this invention aq 
for the requesting process to be unaware of differ- - 
ences in materialization techniques (which may 
vary from day to day or from environment to envi- 
ronment) used to generate the information. - 

It is a further objective of this invention to. 45 
provide a process for materializing or generating 
information about an indeterminate number of pro- 
gramming object types using an indeterminate - 
number of methods of materialization which are 
distributed across an indeterminate number of ma- so 
terialization sites The Information Is returned to the 
requester in a standardized structure. 

In a distributed data processing system com- 
prising a plurality of different computer systems, 
each system having a central processing unit 55 
(CPU), memory, a database stored in the memory, 
and a DBMS a computerized method is provided 
for generating a plurality f bjects in a standard- 



ized format A unique object identifier is associated 
with each of the plurality of objects Each unique 
object Identifier is stored in memory In association 
with at least one object location type or instance, 
an object generation specification for ach object 
location type or instance, and a generation speci- 
fication type For a requested object type at a 
Specified location, an object generation specifica- 
tion and a specification type are identified from the 
Information stored in the computer memory The 
requested object is generated in a standardized 
format from the specified location using the iden- 
tified process type and the identified object genera- 
tion specification. 

In a preferred embodiment, the object fs ma- 
terialized using a standard return format where 
information pertaining to the object is retrieved as 0 
to n data rows. One occurrence of the standardized 
information is represented per data row. The In- 
formation in each row exactly follows' the format 
defined for that object's information, but need not 
follow the forrhat for any other object The object is 
generated (materialized) by one or more generating 
routines or processes, depending on generating 
environment and is conditionally generated, de- 
pending on the presence of end values for param- 
eters (qualifiers) passed to the materializing 
routine(6): Because of the variability of the pres- 
ence of the parameters passed to the materializing 
routines, there is a variable resulting^ "standard- 
ized" object format 

Many of the generating (materialization) pro- 
cesses/routines are shared (used) by 'more than 
one object definition as appropriate, arid, linked to 
the object definition from other object definitions. A 
requester routine, identifies en object identifier, pro- 
vides any required and/or optional perimeters for 
the object specifies a return area In" which the 
standardized information is to be returned, and 
then calls the routines to retrieve the object Unlike 
common Object Oriented Programming practice, 
the code to generate the object instance list is not 
internal to the object, but is instead exfemal to the 
object although It Is not known to the requestor. 
The generation routines are 'externalized" to the 
point that multiple objects can share the generating 
routines. Since the requestor does nek *own - or 
"contain" generating routines, the routines can be 
modified or replaced with minimum impact to all 
the users of the routines. Only the format of toe 
returned data is required to be constant (even 
though it can vary as a result of the passed param- 
eters). Also, since the objects) may exist In several 
different operating environments (such as the IBM 
operating systems VM t MVS, AS/400, OS/2), dif- 
ferent generation routines may be required accord- 
ingly. However, the invention masks the fact that 
different generators may be required (and the fact 
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that the generators may be executing in different 
operating environments), 90 the amount of environ- 
ment-sensitive coding effort in the requestor Is 
reduced accordingly . 

Brief Description of the Drawings 

Rg. 1 is a detailed schematic diagram of a 
computer system; 

Fig 2 is a schematic diagram of a distributed 10 

data processing system; 

Rg„ 3 is a flowchart of the invention; 

Fig. 4 is an object generator table; 

Fig. 5 is a data structure definition for returning 

lists of materialized information to a requester; 75 

Fig 6 is a table showing parameter substitution 

schemes; 

Rg. 7 is an example of a Defined generation 
specification; and 

Figs- 6 and 9 are examples of SQL generation ' 20 
specifications 

Detailed Description of the Invention 

FSg. 1 shows a data processing apparatus 15 25 
with which the present invention may be practiced 
The apparatus 15 comprises a central processing 
unit (CPU) 22, a random access memory- (RAM) 
24, input/output (I/O) port 26 and nonvolatile stor- 
age 28 such as disk storage or read only memory oo 
(ROM), all connected to a common bus structure 
30 The CPU runs or executes program's that are * 
stored in the memory (either, the BAM or the* non- 
volatile storage) Control circuitry 32 performs 
housekeeping operations such as providing appro- 35 
priate clock signals and controlling the operation' of 
the bus 30. An adapter 34 may be used to inter-* 
face to other components that interact with a sys- 
tem user such as a visual display unit or terminal 
36, and user interaction devices such ae a key- 4? 
board 38 and a mouse 40, The implementing envi * 
ronment also includes what is called a window, 
display screen, or view port which provides means 
for displaying rows of data and other Information to . 
the user. The general purpose data processor 15 *& 
shown In Rg. 1 can be used to perform the inven- 
tion under the program control outlined In the 
flowchart of Fig. 3. 

Fig. 2 shows a distributed data processing sys- 
tem 42 where a communication -system 44 js used so 
to interconnect a plurality of computer systems 46. 
Each computer system 46 is similar to the system 
shown in Rg. t and has one or more databases 
stored In the nonvolatile storage and one or more 
database management system (DBMS) programs 55 
run by the CPU to manage the databases. The 
DBMSs can be different types of DBMSs (including 
RDBMSs) with different commands and syntax In 



th preferred embodiment the distributed system Is 
managed from a programmable work station How- 
ever, the system can be managed by any of the 
computer systems. The invention can also be used 
for a single computer system that is not . part of a 
distributed system. 

An object ts anything that can be represented 
as a condition, a state, an occurrence or a relation- 
ship and can be represented by one or more lines 
In a fist processed for programs or displayed on a 
display screen, included in this definition" are: out- 
put from SQL queries, the SQL query itself, a host 
system name, a program status (such as pending 
states), the output of a program (such as OS/400 
authorization returned from a host), and a condition 
such as a lock on an entity. 

In developing programs to manage the distrib- 
uted database system, programmers need to cre- 
ate (materialize) objects relating to the system in 
order to copy, delete, add data items or authoriza- 
tions between systems or determine program or 
system status. 

This invention provides an automated standard- 
ized method for generating a large number of de- 
ferent system ^(pjects in a variety of waya in the 
preferred embodiment there are three types of 
object generators. Objects can be generated that 
are defined by a generation specification* gen- 
erated through the execution of a generation speci- 
fication that is an SQL statement, or generated 
through the execution of a generation specification 
that is a program The three types of generators 
are called, respectively, 'Defined*, b SQL w t end 
"Program" generators. The generation specification 
text is stored in association with an identifier Tor the 
object The object is generated by identifying the 
generation specification text for the object; deter- 
mining what type of generator is used for the 
object generation and processing accordingly (ex* 
editing the SQL statement or program or using the 
specification text 'rtseff as the object): The genera- 
tion specifications can be. used to generate more 
than one object Additional flexibility is achieved by 
incorporating qualifier identifiers In the specification 
text where the program requesting the object sup- 
plies the qualifier substitution values . 

Referring to Rg 3, the first step in ^comput- 
erized process for standardized generation of dif- 
ferent objects is to build an object generator table 
which provides the mapping of the- objects to the 
object's generation specification and generator 
type 46. The table Is also updated as needed with 
new objects and bject generation specifications 
49 All that is required is that the object be as* 
signed a unique identifier 50, an object generator is 
constructed 51 and the information is added to an 
Object Generator Table 52. 
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In order to build the table, a large number ol 
system objects, useful in distributed database man- 
agement programs, are assigned a unique Identifier 
50. Some objects are used in the management of 
the. DBMS and ther objects represent user data s 
entities such as tables, views and indexes* The 
generation specifications for generating the objects 
are also created For objects that are generated 
using programs, the programs are created and the 
specifications for generating the objects are the to 
respective program names For objects that ere 
generated using SQL statements, the SQL state- 
ments are created and the specifications for gen- 
erating the objects are assigned respective -SQL 
statements. For objects that are defined by the *e 
specification, the specifications are assigned the 
respective definition. In that way, the generation 
specifications and associated programs or sets Of 
instructions for generating objects are created for 
each object 51. A table entry is created in the 20 
Object Generator Table for each object to provide 
information on generating the object 52, including 
the object identifier, the object generation type, and 
the generation specifications. More than one gen* 
ration specification can be used to generate an 2& 
object depending on ths location type or Instance 
associated with the object generation: because of 
the different syntaxes of the .OBMSs and operating 
systems of the various computer , systems, in the , 
distributed system. so 

The objects that are generated depend on die ' 
qualifier Identifiers that are provided by the rer 
questing program. For example the same SQL 
statement can produce an "object" consisting of a. 
List of tables for which a particular user ID te as 
authorized or an "object' 3 consisting of a list of > 
table columns for which a different user ID is 
authorized. These object instances can be consid- 
ered the same object and have the same object 
identifier. The same n object" could also be gen- 40 
eratsd using different generation specifications 
where the syntax for the SQL statements used to 
generate the object differs for a different system 

In the preferred embedment, requests for ob- 
jects originate from program routines The objects 4s 
can be displayed on a display device or used by 
other programs A routine requesting an object 
calls the generating routines to automatically co- ■ . . 
ordinate the generation of the object, and Identifies 
the object identifier 74, provides any required or 60 
optional parameters (qualifier values) for the object 
76 including the object location 75, and specifies a • 
return area in which the standardized object is to 
be returned (by th generator routines). 

The object identifier is used as a key to the ss 
Object Generator Table entry which contains the 
value for the corresponding generator type. 80 The 
object identifier and location parameter are used to 



Identify the object generator that is valid for the 
requested object at the requested location 82. 

The way the generation specification is pro- 
cessed dep nds on the generator type 89 (Defined 
90, Program 92, SQL fi4 or Other 96). For the. 
Defined and SQL types of generation specifica- 
tions qualifier substitutions need to be made using 
qualifier values supplied by the requester. For the 
SQL generator, the qualifier identifiers are substi- 
tuted Into the generation specification to produce 
an SQL statement that is run by a DBMS 98. For 
the Defined generator, the substitutions provide the 
object 10Q. For the Program type generators, the 
specification Es a program name to be executed by 
a CPU to. produce the object and qualifier values 
are used as parameters passed to the program. 
The parameters are used by the program to qualify 
the definition of the object 102. The output from the 
the generators is placed in a standardized format 
and returned to the requesting routine 104. 

Referring to Fig 4. the information for generat- 
ing an object la provided m the Object Generator 
Table 110 by th& attribute Columns: OBJECT 
IDENTIFIER 11Z LOCATION 113. GEN-TYPE 114 
and Q€N_SPEC 115 The OBJECT IDENTIFIER 
attribute references the object The LOCATION et- 
trftufe identifies the specific location ft 6 or iocs-, 
tion type 117 .where the object generation speci- 
fication 118 is valid. When the location attribute is 
blank 119, the corfesponcfing generation specifica- 
tion is valid- for .all location types and instances. 
The GEN-TVPE attribute identifies the type of gen- 
erator used to generate the object The BEN-SPEC 
attribute contains the text for the generation speci- 
fication* 

Ths object identifier attributes can be repeated 
on multiple* rows 120 where the corresponding lo- 
cation attributes * are used with the fderrtifier to 
determine the valid generation .specification. Where 
there is- no location attribute specified 119, the 
generation specification is valid for all locations. 
Where the table contains multiple entries for a 
single object identifier, the entries' are sorted: in 
order of increasing generality ami. ctrily the first 
retry is used. So that the first entry Is for a specific 
system 116, the next is for a DBMS type 117, and 
the last is blank, for all other systems arid database 
types : 

The process by which tha generation specifics 
•tion is used Is determined by the attribute value for 
the GEN-TYPE in the same row. In th& portion of 
the Object Generator Tajale shown In Fig 4, the 
first object 120 Is generated by SQL statements 
which are specific to a location instance 116 or 
location types 117 or not specific to any location 
119. The GEN-SPEC for th first object contains 
the text for an SQL statement The second object 
is generated by a program where the' generating 
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program name (PAYROLL2) is listed in the GEN- 
SPEC field The fourth object is has a Defined 
generator type The object Itself is a phone number 
(which could be the phone number for the com- 
puter system operator) e 

• The object generators are either directly listed 
in or referenced by the table generation specifica- * 
tion For defined generators, the GEN-SPEC field 
contains the actual object occurrence definition it- 
self That is, the generated object is the defined to 
generation specification (after qualifier identifier 
substitutions are made) For the SQL generators, 
the GEN-SPEC contains the SQL statement to be 
run (after qualifier identifier substitutions are made) 
by a DBMS. The object occurrence list that Is is 
generated is the output from the SQL statement 
For the program generators the GEN-SPEC con- • 
tains a program name. The program name refers to 
a previously written program requiring input param- 
eters as appropriate. The output from the program 20 
after execution by a CPU is the object occurrence 
list The object occurrence list produced from the 
Defined. SQL or program generators are output to 
the requesting program > * 

The various location operating systems and 25 
DBMSs can use different commands and syntax 
requiring different generators to be used for drf- • 
ferent locations. An advantage of this invention- is 
that the programmers requesting the objects do not 
have to be proficient in each system's operating 30 
system and DBMS: 

A preferred embodiment* of the data structure 
definition' T30 used to contain the returned lists of 
materialized information from the generators wilt b£ 
described with reference to Fig. 5, The structure is 35 
consistent for all objects, but is self-defining so that 
different objects can take different forms (Le,, can 
consist of a different number of attribute values, 
columns, data strings, eta). The returned data 
structure is referred to as the TOOLOUT structure. 40 

Referring to Fig 5. there are two values 

NBR ITEMS 132 end ITEM RAY 133 that are 

returned by the object generator ITEM^RAY is 
the address of a returned array 134.. NBR_IT£MS 
Is the number of entries in the returned array 45 

There is also a return code 135 that' is returned 
by the object generator . The return code identifies 
whether the object was successfully generated and 
if not, it provides information as to what was wrong; 
That is. the return code indicates whether there BO 
was an Invalid identifier, incorrect qualifier, whether 
th generator failed, or whether the object is null 
When the generator fails or no values are returned 
but the generator completed without error (e g , the 
SQL statement retrieved no responses), the 5$ 

NBR_JTEMS is zero and the ITEM RAY has a 

null value. The r turn codes provide the requesting 
routines with information on the reason for there 



being no output 

Referring to the returned array 1 34, 
DATA_TYPE 136 is an encoded data type. In the 
Date_Jype column, the code 462 is Character, 
fixed length, not nulfable; 453 is Character, fixed 
length, nullable; 500 is 16-bit signed integer, not 
nullebte; 448 Is Character, veryfng length", not nul- 
lable; and 496 is 32-bit signed integer, not nullable. 
There are other designations to represent all appro- 
priate data types NULL IND 137 indicates wheth- 
er the data value Is null or not NULL_JND haa the 
value *0" when the data value is not null, n -i" 
when the data value is null, and 'XT when the 
data Value is not null but was truncated, 
DATA_LEN 138 is the length of the data for that 
row. DATA_PTR 139 is a pointer to the' data for 
the object occurrence of that row. An object that is 
the result of an SQL query will consist of a table of 
information. Each row from that table (art occur- 
rence) is stored tn a row of the returned array 

Many other TOQLOOT structures can also be 
used Other data elements that can be included In 
a TOOLOUT structure are CCSIP numbers, ser- 
viceabiBty "eye-catchers' 7 and product 
names/bodes 

Before a Defined or SQL object generation 
specification is used to generate the object occur- 
rences! it is processed -for conditional' text and 
parameter substitution. This is done by comparing 
the qualifier identifiers passed. as- input to those 
contained in th9 text of the object generator. Where 
a match is found conditional text fs included in the 
object generator and the qualifier values associated 
with the qualifier identifier are Incorporated into the 
object generator 

Generation specifications of up to the system 
table Rmit capacity (typically 4000 bytes} can be 
stored directly In the table. Otherwise, Generators 
of any length can be specified In a file. 

The PROGRAM Generation specification for 
the program name to be executed must include the 
full path name or the program should reside in a 
directory in the "path" for the session. The pro- 
gram can then either generate the object directly or 
call other programs either locally or remotely to 
generate the object 

Program generators ere called with the follow- 
ing arguments: A pointer stored in memory to a 
public parameters block (called PUBLlCPARAMs), 
a pointer to a tool input area (TOOLIN), and a 
pointer to a tool output area (TOOLOUT), 

The public parameters block Is an; area of 
memofy which has been arbitrarily mapped into a 
structure Which contains various data values, point- 
ers, other structures and possibly input ami/or out- 
put reas. The tool input area Is an area of memory 
containing the . input parameters, arguments and 
data values (such as the object Identifier) ^required 
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or usable by the program. The toot output area Is 
an ansa of memory where the program returns the 
list of occurrences. The tool output area Is updated 
by the program to contain the. returned object oc- 
currences list The object occurrences to be re- 5 
turned must be returned in the tool output area as 
new occurrences since the TOOLOUT structure Is 
initially empty 

The program generators returns a code which 
indicates whether the process was successfully w 
completed. Program generators can return the fol- 
lowing return codes in the tool output structure: OK 
- normal completion; GENERATOR__FAILED - er- 
ror in executing the generator; and 

NO OCCURRENCES - no object occurrences ts 

which satisfy the supplied qualification were found; 
and other return codes as described in more detail 
below 

An example of a. program generation specifica- 
tion is C:\GENER EXE- The program GENEREXE 20 
accepts parameters such as RDB-name .and year. 
As an example, me values for the parameters are 
SYDVM1 and 1990. The qualifiers are put in a tool 
input structure and the program Is invoked and 
passed pointers to PUBUCPARAMS. TOOLlN and 2$ 
TOOLOUT to return the results- All the memory for 
these sfructures and data areas is in the shared 
memory. If values for the program parameters (in 
PUBUCPARAMS) is located, at memory address 
3333333333, the program tool in 0" TOOLlN) Is 
located at memory address 655555555$, and the 
program tool out (in TOOLOUT) is located at mem* 
ory address 688B888888» (where all addresses are 
expressed as a decimal string equivalent of the 
actual memory address and the present implemerv 
. tation requires these addresses to be in the range 
of 1 to 2 ~ 32-1) then GENER Is invokect es a child 
process with * the following arguments: 
-C:\GENER.EXE .3333333333 5555555555 
8888838888" 

The Defined generators are treated as a text 
string only. The generator- can be a SQL statement 
but if so it will not be executed as SQL The text 
string will be parssd for substitution parameters, 
any matching substitution parameters wBI be re- 
placed with the values supplied by the requester, 
unmatched substitution parameters wiH be 
"pruned", and the resulting string will be returned 
to the caller, along with a return code to indicate 
success/failure of the call SQL generators are 
parsed similar to the Defined generators, but are 
also executed as SQL statements 

An example of the parsing substitution is ex- 
plained with reference to Pig. 6. Fig. 6 is an exam- 
ple of a generation specification of a Defined or sa 
SQL object (the difference being whether rt is ex- . 
ecuted as SQL • which is determined by the ob- 
ject's generator type value). 



For ease of illustration, uppercas _ charact rs 
are used for the unsubstftuted text values and 
lowercase characters are used to represent names 
of substitution parameters. The method is actually 
case insensitive. 

Referring to the generation specification 150, 
the parameter arguments are sometimes preceded 
by an an exclamation point (T) 161, for example, 
location 152, table 154, index 156, user 158 and 
view 160- This indicates to the substitution routine 
that the values supplied for the respective input 
parameters are to replace the and parameter 
argument. Thus, referring to the result after, sub- 
stitution 161, the resulting data string does not 
contain any Ts or parameter argument names, 
only substituted data values from the passed val- 
ues Qst 182, 

There are also occurences . of data strings 
which are enclosed in braces "Each such 
string is a conditional text string which will be 
pruned (discarded) if certain test conditions are not 
met (i a, result (n a FALSE result). The test con- 
dition Is Initially assumed to be TRUE, but will be 
set to FALSE If an optional test specification at the 
front of the enclosed string results in a FALSE 
result when evaluated. Hie test specification con- 
sists of one or more input argument "names with 
optional AND, OR, arid NOT operators" separating 
them to comprise a Boolean expression' terminated 
by a colon- 

When the generation specification .150 is used 
with the passed input parameters shown as 170 
where input parameter arguments passed are Joca- 
tfon 172, table 174, and user 176, and the respec?, 
tfve data values for the parameters are Rl -1:78, 
SYSV1EWS 180, FRED 182 and REM 84, Note- 
there are two data values 182, 184 for ihe : ar- 
gument name USER 178? This Indicates that for 
substitution purposes conditional clauses .175 
which use the Argument USER 176'are to.be 
repeated as many times as there are. values 
182,184 for the argument name USER 178 in quali- 
fier identifier parameters passed to the 'substitution 
routine 186 

Procedures followed for parameter, substitution 
are farther clarified with references to the param-. 
eter substitution examples shown in Fig 7 Tfte. 
chart 180 In Fig. 7 shows portions of text from 
generation specifications 194, the qualifier identifi- 
ers 195, the values for the qualifiers 183 (supplied 
by the requester), and the resulting values- 1 87. 

TTie argument values to be Incorporated into, 
the text Statement of the generation specification 
are indicated by H P followed by a qualifier Identifier 
which must match one of the qualifier identifiers 
passed as input The *P and qualifier identifier are 
replaced with the qualifier value and anything sur- 
rounding the qualifier is not changed (see 200- 



,35 



40 



4$ 



60 ' 



7 



Davidson Berquist 



Fax:703-248-9558 



Jan 7 2005 15:23 



P. 20 



13 EP069204SA1 14 



208). No additional formatting is dona If no match 
is found on the Input, processing cannot continue 
and a return coda of 

NO VALUE FOR REQUIRED PARM Is re- 
turned wrth the empty TOOLOUT 

Conditional values 220 and text 222 are en- 
closed in braces (}- Following the opening brace 

is a list of qualifier identifiers 226 The lest 
qualifier identifier is followed by colon ":■ 228. The 
qualifier Identifiers are separated by a bar "|" (sym- 
bolizing the logical OR operation) or ampersand 
(symbolizing the logical AND operation) and 
ere evaluated from loft to right The contftional text 
222 enclosed in braces {} f s 224 are only included, 
in the generation specification when the qualifier 
Identifier expression (preceding the colon) evalu- 
ates to TRUE. The presence Of a qualifier identifier 
represents TRUE and the absence of a qualifier 
identifier represents FALSE The use of parenthe* 
ses to nest qualifier Identifiers is not supported. 
However, the conditional clauses can be nested as 
shown In 250*260 

There are some special cases for qualifier sub- 
stitutions that are used. For example, the asterisk 
character ^ In qualifier values is converted to -a 
percentage character "%* because SQL treats the 
percentage character "% w as a wild card character 
and and OS/400 use the asterisk character M as a 
wild card character. 

SQL keywords are also recognized during the 
qualifier substitution -process If after conditional 
text substitution, the string "ORDER BY P is not 
followed by any other text, it Is removed. Also if 
after conditional text substitution, the string 
"GROUP BY" Is followed by one of the following 
strings, H is removed:. "HAVING*, "UNION*, *)". 
"ORDER BY" Conditional clauses after the 
'WHERE" or "HAVING" clause ere handled In a 
special way If the first clause Is a conditional 
clause which is to be dropped and the foflovring 
token is "AND" or "OR", the "AND" or "OR* is 
removed. If other conditional clauses are to t»e 
dropped then the preceding token (which is an 
"AND" or "OR") rs also dropped. Also, if after 
conditional text substitution, the string "HAVING" is 
followed, by one of the following strings, it is re- 
moved: "UNION", -)VORDER BY". Also, if after 
conditional text substitution, the string "WHERE* is 
followed by the string "GROUP BY*, -HAVING". 
"UNION", or ")". "ORDER BY", it is removed. 

When a single qualifier Identifier 272 has mul- 
tiple values 274 the conditional clause is repeated 
for each value wrtn these clauses 276 ORed to- 
gether (see 270). When multiple qualifier identifiers 
have multiple qLiafifier values 282, 283. the qualifier 
values are paired for each qualifier identifier (se 
280) This pairing is based on the order in which 
the qualifiers are passed in th area of the TOOLIN 



structure which contains the passed .argument 
names and values (referred to as the PQUAL struc- 
ture). This means that when more than one qualifier 
identifier is to be substituted within a conditional 
5 clause, all such qualifier identifiers must ^ have the 
same cardinality, rf this is not true, the return cod© 
NO_VALUE_FOR_REQUIRED_PARM is re- 
turned. 

SQL Generators am similar to Defined gener- 
ic ators but the resulting text after substitution Is 
executed at the relational database specified by the 
RDBNAME parameter (RDBNAME Is always a re- 
quired qualifier for SQL object generators). The 
RDBNAME qualifier can also be used as a qualifier 

?$ for substitution.- The first word of the SQL generator 
must.be "SELECT*. If not then the return code 
GENERATOR_FAILED is returned. The (feneration 
specification text string itself (after substitutions) is 
not returned to the caller Instead, the results of the 

20 SQL operation are formatted into the appropriate. . 
data structure and returned to the caller * 

Example of SQL generators can be explained 
with reference to Figs, 8 and 9. 

Referring to Fig 8, the generation specification 

2s text 300 contains qualifier identifiers 302 The 
qualifier identifiers 302 are assigned values 304 
provided by the requester. The substitutions are 
made to produce the SQL statement 308 executed 
to generate the object occurrences in the relational 

W .database specified 308. The execution of the SQL 
generator returns the object occurrence m the ob- 
jects format 310 

Referring to Rg. 8, buffer pool authorizations 
for a user ID is the object to be generated The 

35 object identifier for that object is used to find the" 
entry in the Object Generator table for the gener- 
ator type which is SQL The location specified 
along with the object identifier is used to find the 
valid generation specification 320 to generate the 

40 object The requester also supplies the qualifier 
values 322 needed for the qualifier identifiers 324 
in the generation specification text 320. The qualifi- 
ers 324 are the RDB name, the location, the buffer- 
pool ID, and the user ED. The. SQL statement 324 

<5 resulting from the qualifier substitutions tq'the gen- 
eration specification 320 is executed in the "Rl* 
RDB 326. The qualifier Substitution values provide 
that the object generated 328 is that the user ID 
"FRED" 327 has authority for buffers DPI 329 and 

50 BP32K 330 In RDB Rl The SQL generator needed 
to make an assumption about a parameter which is 
relayed to the requester as a massage 332. 

The generators are thus used to generate a 
wide range of objects used by programs for main- 

ss taining a distributed database system, such as FJsts 
of User. IDs, status of programs, end iste of host 
systems. Using the object generator routines, a 
programmer does not have to be familiar with each 
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systems operating system r each DBMS. More- 
over, the generation process does not have to be 
changed to add new types of objects or even new 
ways of generating objects. The Object Generator 
Table is changed, but the togic for using the gener- 
ators is unchanged. Additionally, the program used 
to generate one object can also be used to gen- 
erate other objects by altering the qualifier substitu- 
tions. The fact that the logic for materializing the 
objects id not part of the object definition, provides 
edded flexibility 

While the invention has been particularly 
shown and described with reference to a preferred 
embodiment thereof, it will be understood by those 
skilled in the art that various other changes in. the 
form and details may be made therein without 
departing from the spirit and scope of the inven- 
tion. Accordingly, the method and system herein 
disclosed are to be considered merely as illustra- 
tive and the invention Is to be limited only as 
specified in the claims. 

Claims 

1. In a data processing system comprising a cen- 
tral processing unit (CPU), memory, at least 
one database stored In the memory, and a 
plurality of database management systems 
(DBMSs), wherein at bast one DBMS is de- 
ferent from at least one other. DBMS, a.cottv- 
puterteed method for generating a plurality of 
objects in a standardized format comprising 
the steps of, 

(a) associating a unique object identifier 
with each of the plurality of objects; 

(b) storing In a. computer memory «ach 
unique object identifier in association with- at 
least one object location, an object genera- 
tion specification for. each object location, 
and e generation specification type; 

(c) for a requested object and a specified 
location; identifying from the computer 
memory, an object generation specification, 
and a generation specification typej.and 

<d> generating in ^ standardized format the 
requested object using the identified gen* 
oration specification type and the identified 
object generation specification. . 

2. The method of claim 1 wherein the object 
generation specification contains at least one 
qualifier identifier and requester supplied quali- 
fier values are substituted for each qualifier 
identifier 

a The method of claim 1 wherein the requested 
object is the object generation specification 
having a requester supplied qualifier value 
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substituted for each qualifier identifier in the 
object generation specification, 

4. The method of claim 1 wherein the object Is a 
s result of the object generation specification, 

having a requester supplied qualifier value 
•substituted for each qualifier identifier in the 
object generation specification, executed as an 
SQL statement by a DBMS 

10 

5.. The method of claim 1 wherein the object is a 
result of the object generation specification ex- 
ecuted as a program, by a CPU wfth a re- 
quester supplied qualifier value substituted for 
76 each qualifier Identifier program parameter. 

& The method of claim 1 wherein tfte standard- 
ized format comprises a pointer .'to the re- 
quested object with an indicator of the size of 
20 the requested object. 

7» The method of claim 1 wherein each unique 
object identifier. Is stored in a set! of at least 
one table in association with at least one object 
25 location* an object generation specification for 
each object location, and a generation speci- 
fication type 

a The method of claim 7 further comprising the 
. so step of adding a new object Identifier and 
associated information to the set of at least 
table. 

... £ 

9- In a distributed data processing system having 
35 a. plurality of different computer systems, each 
system having a central- processing unit (CPU), 
memory, a database stored in the memory, 
and a DBMS, a system for generating a plural- 
ity of objects in a. standardized format from 
40 . each of the computer systems, comprising: 

means for associating • a unique object 
identifier with each of the plurality of objects; 

means for storing in a computer memory 
each unique object identifier in association with 
45 at teast one object location, an object genera- 
tion specification for each object location, and 
a specification type; 

means for Identifying from the computer 
memory, an object generation specification, 
go and a generation specification type; and 

means for generating In a standardized 
format the requested object using the identified 
generation specification type and the Identified 
object generation specification 

10. The system of claim 9 wherein the object 
generation specification contains at least one 
qualifier Identifier and requester supplied quali- 
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tier values are substituted tor each qualifier 
identifier. 

11. "me system of claim 9 wherein the requested 
object is the bject generation specification 5 
having a requester supplied qualifier value 
substituted for each qualifier Identifier In the 
object generation specification 

12, The system of claim 9 wharein the object is iq 
the result of the object generation specifica- 
tion, having a requester supplied qualifier value 
substituted for each qualifier identifier in the 
object generation specification, executed as an 
SQL statement by a DBMS. 75 

IS. The system of claim* 9 wherein the object is 
the result of the object generation specification 
executed as a program by a CPU with a re- 
quester supplied qualifier value substituted for 20 
each qualifier identifier program parameter. 
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A) GENERATOR TEXT : 

<Cfi — • t— — — -™ «^ 

"V SE^ 01 '^location, NAME, CREATOR ] 
FROM SYS18M.!toble 
| WHERE "~ 154 s~15&^—158 I 

I 1 "{index; NAME UKE 'tindex'j/W 



I 



user: CREATOR LIKE luseff AND I « 
view: NAME UKE 'IviewT^^ 1 



^ ORDER BY {index: NAME} {vlew&index: ,| {view: CREATOR] J 



178* ^ 162 



7 °~N^QuaJifier Identifier : location T Values : R1 s-toT) J 
, . table -^W , . .SYSYIEWS , , 

1 user ^-'^ I fRED'— ;«2 I I 

us a^r!L 6 X ^'z^il 84 J ) 

generator after substitution is: ] 
SELECT 'Rl\ NAME, CREATOR 

FROM SYSBM.SYSV1EWS ' 

WHERE ((CREATOR LIKE 'FRED') A ND (C REATOR UKE 'REff)) | 

L J 

full name = RENAME. CREATOR 
short name = none 
messages = none 



Davidson Berquist 



Fax:703-248-9558 Jan 7 2005 15:24 

EP 0 592 045 A1 



^- 194 

GENERATION 
SPECIFICATION 
TEXT 



r 195 
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202 198 f99 

206 ->> W 
208^ *!5' 
!6 

220, S~~Z$ 5 

|1&2:and} 
226^ 

|1&2:andJ X 
|l|2:or} X 



j1|2-or| X % 
|1&zl3:and/orf X 
|1&2 1 3: and/or} X 



250 

^A|1:4I1{2:+!2}}=D 
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JOhy 



Generator Text : 

/ 

SELECT 'nocation'. 7, CREATOR, 7. 'f, NAME, 'f 
FROM SYSIBM.SYSINDEXES 

WHERE r 502 
user CREATOR UKE 'Juser] AND 

'source_col!ectlon*tQble:7BCREATOR LIKE , 302 

Msourcfi collection' AND TBNAME LIKE t table! 



302 



rdbname Values ; 


R1 


source„rdbname 


Rl 


source^coflection 


FRED 


table 


Tl 


location 


RbdNew 


user 


U1 



304 



the following SQL statements pre executed to generate the object 
occurrences : 

/CONNECT TO Kl^M8 

306*>! SELECT 'RdbNevr*. 7. CREATOR, 7//, NAME, 'f 
I FROM SYSIBM.SYS1NDEXES 
\ WERE (CREATOR LIKE W) AND 
\ (1BCREAT0R LIKE *FRED' AND TBNAME UKE 'If) 

310 •>/ The object occurrence format Is 
\ full name = 1*d>New\CREAT0RJMME 
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e) Generator Text (Bufferpooi Auths) 



332 



f~324 



I SELECT USEAUTH, V, GRANTEE, V, '153'. 7, NAME, % 
I . '3333T, NAME* GRANTEE. USEAUTH 



\ 



320-^ FROM SYS1BM.SYSRESAUTH 324 

WHERE |13: NAME LIKE '!13l 

AND {5: GRANTEE LIKE 'lift _ 

ORDER BY NAME, GRANTEE ^t*^ 

f-324 

Qualifier identifier : 23 (rdbname) Values : R1 

53 (location) R1 
13 (buffer pool Id) BP* T « 7 

5 (userid) FRED ^ 

The following SQL statements are executed to generate the object 
occurrences : 

^- 326 
CONNECT TO R1 

/ SELECT USEAUTH. 7. GRANTEE, 7, 1R1* , 7. NAME, 'f. 
J25 W , 3333I\ NAME, GRANTEE, USEAUTH 

FROM SYSI BfcLSYSRESAUTH 
I WHERE NAME LIKE *BP** 
\ AND GRANTEE LIKE *r*R£D' 
ORDER BY NAME, GRANTEE 

Assuming that FRED has USE authority on BPI and BP32K, the 

following will be the results: 329 

( ^-328 

full name (up to second #): Y.FRED.R1.BP1 

Y,FRED.R1.BP32K/""< X5£? 



short name (between first and second #): NULL 

message line (assuming 33331 is "W \t&2 
VW): 
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